Automated accident detection, fault attribution, and claims processing

ABSTRACT

A communication module may receive communications from a vehicle. A collision detection module may determine that a collision has occurred at a vehicle based on one or more of the communications received from a vehicle. A participant identification module may identify one or more participants involved in the collision based on one or more communications received from the vehicle. A fault determination module may identify one of the participants as the at-fault participant based on a comparison of a fault determination ruleset to vehicle telematics data included in one or more of the communications received from the vehicle. A claims processing module may determine whether to file an insurance claim associated with one of the participants based on the estimated repair cost.

TECHNICAL FIELD

The present invention relates in general to processing insurance claimsand relates in particular to automated collision detection, faultattribution, and insurance claims processing.

BACKGROUND

Processing an insurance claim following a vehicle accident can be acomplex and time-consuming process. Individuals involved in the accidentmust exchange insurance information and file insurance claims. Insurancecompanies for the individuals involved in the accident must determinethe amount of damage caused to the vehicles, pay out on insuranceclaims, and recover damages from the liable party.

Current claims processing approaches may involve interaction withmultiple insurance agents, claims adjusters, subrogationrepresentatives, and the like. Accordingly, current approaches to claimsprocessing may include the processing of paperwork, telephone calls, andface-to-face meetings. As a result, a significant amount of time canelapse between the time the claim is filed and final settlement of theclaim.

Therefore, a need exists for improved approaches to processing insuranceclaims in response to a vehicle accident.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects of the disclosure. The summary is not anextensive overview of the disclosure. It is neither intended to identifykey or critical elements of the disclosure nor to delineate the scope ofthe disclosure. The following summary merely presents some concepts ofthe disclosure in a simplified form as a prelude to the descriptionbelow.

A communication module may receive communications from a vehicle orsensors attached to a vehicle. A collision detection module maydetermine that a collision has occurred at a vehicle based on the one ormore of the communications received from a vehicle or sensors attachedto a vehicle. A participant identification module may identify one ormore participants involved in the collision based on one or morecommunications received from the vehicle or sensors attached to thevehicle. A fault determination module may identify one of theparticipants as the at-fault participant based on a comparison of afault determination ruleset to vehicle telematics data included in oneor more of the communications received from the vehicle or sensorsattached to the vehicle. A repair cost estimation module may calculatean estimated repair cost based on vehicle diagnostic data included inone or more of the communications received from the vehicle or sensorsattached to the vehicle. A claims processing module may determinewhether to file an insurance claim associated with one of theparticipants based on the estimated repair cost.

Aspects of the disclosure may be provided in non-transitorycomputer-readable media having computer-executable instructions storedthereon that, when executed, cause a processor of a computing devicecause the processor to perform one or more of the processes described inthis disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustrative environment in which various aspects of thedisclosure may be implemented.

FIG. 2 is an example of an implementation of an operating environment inwhich various aspects of the disclosure may be implemented.

FIG. 3 is an example of an implementation of network devices and serversthat may be used to implement the processes and functions of certainaspects of the present disclosure.

FIG. 4 is an example of an implementation of an insurance managementsystem.

FIG. 5 is a flowchart of example method steps for detecting andresponding to a collision.

FIG. 6A is a flowchart of example method steps for detecting acollision.

FIG. 6B is a flowchart of alternative example method steps for detectinga collision.

FIG. 7 is a flowchart of example method steps for automaticallyidentifying the participants involved in a collision.

FIG. 8 is a flowchart of example method steps for automaticallydetermining and attributing fault to one of the participants involved ina collision.

FIG. 9 is a flowchart of example method steps for automaticallydetermining a total estimated repair cost for a vehicle involved in acollision.

FIG. 10 is a flowchart of example method steps for automaticallyprocessing an insurance claim resulting from a collision.

FIG. 11 is a flowchart of example method steps for automaticallydetecting and responding to a collision involving a parked vehicle.

DETAILED DESCRIPTION

Aspects of the present disclosure are directed towards automatedcollision detection, fault attribution, and insurance claims processing.Referring to FIG. 1, two individuals 100 a, 100 b may experience avehicle collision, e.g., an accident. Wireless communication devices 102a, 102 b at each vehicle 104 a, 104 b may wirelessly communicate with anautomated collision detection, fault attribution, and claims processingsystem 106. The automated collision detection, fault attribution, andclaims processing system 106 may be additionally or alternativelyreferred to as an insurance processing system. Communications may beexchanged between the system 106 and a mobile device 108 a, 108 boperated by the individual 100 a, 100 b, respectively, via, for example,a network 110. The system 106 may automatically detect that a collisionhas occurred, automatically determine which individual 100 a or 100 b isat fault for the accident, and manage subsequent insurance claimsresulting from the accident. The system 106 may also communicate withthe individuals 100 a, 100 b via respective mobile devices 108 a, 108 boperated by the individuals. It will be appreciated that, in someinstances, more than two individuals may be involved in an accident. Itwill also be appreciated that, in some instances, a single vehicle maybe involved in an accident. For example, an individual may hit a pole ora wall or the individual may forget to set a parking brake causing thevehicle to run away on its own. Accordingly, aspects of this disclosureare also applicable in situations where a single vehicle is involved inan accident.

As used throughout the description, the various terms may be used torefer to the entities involved or associated with the automatedcollision detection, fault attribution, and claims processingprocedures. A participant in this context is an individual 100 a, 100 bwhose vehicle 104 a, 104 b was involved in a collision. A participantmay or may not be a customer of an insurance provider that providesinsurance coverage. In some instances, participants may be customers ofthe same insurance provider while in other instances the participantsmay be customers of different insurance providers. An insurance providermay be referred to as an insurer, and a customer of the insurer may bereferred to as an insured. The insurer may provide and operate theinsurance management system 106 to automatically detect collisions, toautomatically determine and attribute fault, and to automaticallyprocess insurance claims resulting from the vehicle collision.

Each participant in the vehicle collision may be insured by theinsurance provider that operates the insurance management system 106. Insome situations, the participants may be respectively insured bydifferent insurance providers in which case one of the participants maybe described as being insured by a third-party insurance provider, e.g.,a third-party insurer. The third-party insurer may operate a third-partyinsurance management system that also automatically detects collisions,determines and attributes fault, and processes insurance claims.

As a result of a vehicle collision, respective insurance claims may befiled by one or more of the participants. Accordingly, a claimant may bea participant for which an insurance claim has been filed. The claimantmay be insured by the insurance provider or the third-party insuranceprovider. In other words, the claimant may or may not be a customer ofthe insurer that operates the insurance management system. In addition,the claimant may or may not be the at-fault participant, e.g., theparticipant to whom fault for the collision is attributed and liabilityassigned.

Moreover, a collision is but one type of physical disturbance event thatmay occur involving a vehicle. Stated more broadly, aspects of thedisclosure are directed towards determining when a physical disturbanceevent or incident occurs at a vehicle. A physical disturbance may be,for example, two moving vehicles impacting one another, one movingvehicle impacting a stationary object (e.g., a non-moving vehicle, aparked vehicle, a wall, etc.), a towing of the vehicle, a break-in orburglary at the vehicle, and other events that physical disturb thevehicle. While aspects of the disclosures set forth below are describedin the context of vehicle collisions, it will be appreciated that thedisclosures are also applicable to other physical disturbance eventsinvolving the vehicle.

The insurance management system 106 provides a number of advantages byautomating aspects of responding to collisions. As an example, theinsurance management system 106 advantageously reduces the cost, time,and effort involved in processing and resolving an insurance claim byautomating aspects of the claim processing and resolution process. Theinsurance management system 106 may automatically collect informationrelating to the collision, automatically determine and attribute faultto one of the participants, automatically estimate the cost to repair adamaged vehicle, and automatically provide settlement offers toparticipants involved in vehicle collisions. Moreover, by automatingaspects of responding to vehicle collisions, the insurance managementsystem 106 may advantageously provide automated settlement offers withina relatively short timeframe after the collision occurred. The insurancemanagement system 106 described below also advantageously reduces thecost, time, and effort associated with subrogation by automating aspectsof the subrogation process. These and other aspects will be discussedfurther below.

Referring to FIG. 2, an example of an implementation of an operatingenvironment in which various aspects of the disclosure may beimplemented is shown. In accordance with various aspects of thedisclosure, methods, computer-readable media, and apparatuses aredisclosed through which collisions may be automatically detected, faultautomatically determined, and insurance claims automatically processed.In certain aspects, when an insurance management system receives dataregarding a collision (e.g., from a vehicle), the insurance managementsystem processes the data and manages the various automated proceduresinvolved in responding to the collision.

The automated procedures may utilize various hardware components (e.g.,processors, communication servers, memory devices, sensors, etc.) andrelated computer algorithms to detect that a collision has occurred,identify the participants involved in the collision, determine whichparticipant was at fault, calculate an estimated repair cost, processany resulting insurance claims, and detect attempts at fraud.

FIG. 2 illustrates a block diagram of an insurance management system 200(e.g., a computer server) that may be used according to an illustrativeembodiment of the disclosure. The server 201 may have a processor 203for controlling operation of various aspects of the insurance managementsystem 200 and its associated components, including RAM 205, ROM 207,input/output module 209, and memory 215. The insurance management system200 may include multiple servers 201 for controlling operation ofrespective aspects of the insurance management system.

I/O module 209 may include a microphone, keypad, touch screen, stylus,and/or other input sources through which a user of the server 201 mayprovide input, and may also include one or more of a speaker forproviding audio output and a video display device for providing textual,audiovisual, and/or graphical output. Software may be stored withinmemory 215 to provide instructions to processor 203 for enabling server201 to perform various functions. For example, memory 215 may storesoftware used by the server 201, such as an operating system 217,application programs 219, and an associated database 221. Processor 203and its associated components may allow the server 201 to run a seriesof computer-readable instructions to detect that a collision hasoccurred, identify the participants involved in the collision, determinewhich participant was at fault, and process any resulting insuranceclaims. The server 201 may operate in a networked environment supportingconnections to one or more remote computers, such as terminals 241 and251. The terminals 241 and 251 may be personal computers or servers thatinclude many or all of the elements described above relative to theserver 201. Also, terminal 241 or 251 may be data stores for storingdata relating to the collision as well as the vehicles and participantsinvolved in the collision. In yet other embodiments, terminals 241 and251 may represent mobile devices respectively operated by theparticipants involved in the collision.

The network connections depicted in FIG. 2 include a local area network(LAN) 225 and a wide area network (WAN) 229, but may also include othernetworks such as a metropolitan area network (MAN) or a cellularnetwork. When used in a LAN networking environment, the server 201 isconnected to the LAN 225 through a network interface or adapter 223.When used in a WAN or MAN networking environment, the server 201 mayinclude a modem 227, the network interface or adapter 223, or othermeans for establishing communications over the WAN 229 (or MAN), such asthe Internet 231. It will be appreciated that the network connectionsshown are illustrative and other means of establishing a communicationslink between the computers may be used. The existence of any of variouswell-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like ispresumed.

Additionally, an application program 219 used by the server 201according to an illustrative embodiment of the disclosure may includecomputer executable instructions for invoking functionality related todetect that a collision has occurred, identify the participants involvedin the collision, determine which participant was at fault, and processany resulting insurance claims. As noted above, multiple servers 201having respective application programs 219 may be employed to implementand invoke this functionality. The insurance management system 201and/or terminals 241 or 251 may also be mobile terminals includingvarious other components, such as a battery, speaker, camera, andantennas (not shown).

The disclosure is operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well-known computing systems, environments, orconfigurations that may be suitable for use with the disclosure include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, and distributed computingenvironments that include any of the above systems or devices, and thelike.

The disclosure may be described in the general context ofcomputer-readable instructions, such as program modules, that areexecutable by a processor of a computer. Generally, program modulesinclude routines, programs, objects, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The disclosure may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices orsystems that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including non-transitorymemory storage devices, such as a hard disk, random access memory (RAM),and read only memory (ROM).

With reference to FIG. 3, a system 300 for implementing methodsaccording to the present disclosure is shown. As illustrated, the system300 may include one or more network devices 301. The devices 301 may belocal or remote, and are connected by one or more communications links302 to a computer network 303 that is linked via communications links305 to an insurance management system 304. In certain embodiments, thenetwork devices 301 may run different algorithms used by the insurancemanagement system 304 for detecting that a collision has occurred,identifying the participants involved in the collision, determiningwhich participant was at fault, and processing any resulting insuranceclaims. In yet other embodiments, the network devices 301 may representmobile computing devices utilized by the participants involved in thecollision to exchange communications relating to the collision. Insystem 300, the insurance management system 304 may be one or more ofany suitable server, processor, computer, or data processing device, orcombination of the same.

Computer network 303 may be any suitable computer network including theInternet, an intranet, a metropolitan area network (MAN), a wide-areanetwork (WAN), a local-area network (LAN), a wireless network, a digitalsubscriber line (DSL) network, a frame relay network, an asynchronoustransfer mode (ATM) network, a virtual private network (VPN), or anycombination of any of such networks. Communications links 302 and 305may be any communications links suitable for communicating between thenetwork devices 301 and the insurance management system 304, such asnetwork links, dial-up links, wireless links, hard-wired links, etc. Theexample method steps discussed below may be implemented by one or moreof the components in FIGS. 2-3 or other components, including othercomputing devices.

Referring now to FIG. 4, an example of an implementation of an insurancemanagement system 400 for automatically detecting a vehicle collision,attributing fault, and processing insurance claims is shown. Theinsurance management system 400 is in signal communication with avehicle 402 such that the insurance management system is capable ofdetecting a collision involving the vehicle and exchangingcommunications with the vehicle. The insurance management system 400 mayalso be in signal communication with one or more mobile computingdevices 404 operated by the collision participants such that theinsurance management system is capable of exchanging communications withthe mobile computing devices.

The insurance management system 400 may receive data from the vehicle402 including, for example, vehicle identification data, vehicletelematics data, collision data, and vehicle diagnostic data. In someexample implementations, the insurance management system 400 may receiveparticipant identification data (e.g., name, customer number, etc.) fromthe vehicle 402 as well. The vehicle 402 may include various componentsto collect and provide this data to the insurance management system 400.It will be appreciated that these components may be interconnected andin signal communication with each other via various vehicle busses (notshown).

The vehicle 402 may include, for example, a collision response module(CRM) 406 for coordinating the operation of the other vehicle systems,devices, and components in response to a collision involving thevehicle. As noted above a collision may be one type of physicaldisturbance event that can occur involving the vehicle. Accordingly, thecollision response module 406 may additionally or alternatively referredto more broadly as a disturbance response module. In this regard, thecollision response module 406 may be understood as a type of controllerthat interacts with various vehicle systems, devices, and components inorder to obtain data that is utilized when responding to the collision.As an example, the collision response module 406 of the vehicle 402 maybe in signal communication with: an automated collision notificationdevice (ACN) 408 that automatically detects vehicle collisions andprovides notifications of a vehicle collision; a motor vehicle eventdata recorder (MVEDR) 410 that records event data relating to theoperation of the vehicle prior to or during a collision; and an on-boarddiagnostic unit (OBD) 412 that monitors vehicle systems, devices, andcomponents and provides diagnostic data relating to the health, status,or condition of these components. The CRM 406, ACN 408, MVEDR 410, andODB 412 may include one or more respective memories (not shown) forstoring and retaining data relating to the condition, status, oroperation of the vehicle 402 for both normal driving events andcollision events. The CRM 406 of the vehicle 402 may additionally be insignal communication with one or more recording devices, e.g., audiorecording equipment 414 and video recording equipment 416 (A/Vequipment) that respectively records audio data and video data at thevehicle. Furthermore the CRM 406 may be in signal communication withcommunication equipment 418 for transmitting the data from thesecomponents via a network to various systems, such as, for example, aninsurance management system 400. The communication equipment 418 of thevehicle 402 may be configured to wirelessly communicate via, forexample, a cellular network or an internet protocol-based network (IP).It will be appreciated that the communication equipment 418 may beconfigured to wirelessly communicate using additional or alternativeapproaches for wireless communication.

The ACN 408 may include components for automatically detecting vehiclecollisions and providing notifications of the vehicle collision. Thoseskilled in the art will recognize that these components may include, forexample, one or more accelerometers 420 (e.g., triaxial accelerometers)for detecting changes in the velocity of the vehicle 402, a locationdetermination device 422 such as a Global Positioning System (GPS)receiver for determining the geographic location of the vehicle, andcommunication equipment 424 for transmitting one or more collisionnotification messages. Based on the changes in velocity detected by theaccelerometers 420, the ACN 408 may determine that a collision hasoccurred. The ACN 408 may then prepare a collision notification messagethat includes, for example, vehicle identification data, GPS locationdata, and collision data. The communication equipment 424 of the ACN 408may similarly be configured to communicate wirelessly, for example, viaa cellular network or an IP-based network. The ACN 408 may transmit thecollision notification information to, e.g., an insurance managementsystem 400. In some example implementations the ACN 408 may transmit thecollision notification message directly to the insurance managementsystem using the communication equipment of the ACN. In other exampleimplementations, the ACN may transmit the collision notification messageto the CRM 406, which may in turn utilize the communication equipment418 of the vehicle 402 to transmit a corresponding collisionnotification message to the insurance management system 400. It willalso be appreciated that in other example implementations, the vehicle402 may respectively include the individual components of the ACN 408(e.g., the accelerometers 420, the GPS receiver 422, etc.) rather thanthe ACN itself and utilize these components in conjunction with the CRM406 and the communication equipment 418 of the vehicle to detect andprovide notifications of a collision.

The MVEDR 410 may also be referred to a vehicle “black box” (e.g., acrash-proof memory device) that records vehicle telematics data. Vehicletelematics data refers to technical information relating to the statusor operation of the vehicle 402 prior to or during a vehicle event suchas a collision or other physical disturbance event involving thevehicle. As noted above, individuals involved in or associated with thephysical disturbance event may be referred to as participants, andparticipants may or may not be customers of an insurer that operates theinsurance management system 400.

Vehicle telematics data may include, for example, directionalacceleration and deceleration (e.g., forward/backward, left/right,up/down), change in directional acceleration, vehicle speed or velocity,engine throttle and RPM (revolutions per minute), steering input,engagement of various vehicle subsystems (e.g., stability controlsystems, antilock brake systems), and the like. Those skilled in the artwill appreciate that the MVEDR 410 may be configured to collect andrecord other types of data relating to the operation and status of thevehicle 402 prior to or during a vehicle event.

The OBD 412 is a system configured to continuously monitor variouscomponents of the vehicle 402 such as the powertrain, chassis, and bodyof the vehicle as well as various automotive devices. The OBD 412 maycollect and report automotive diagnostic data in accordance with theOBD-II protocol standard. The OBD 412 may be in signal communicationwith an engine control unit (ECU) 424 and the transmission control unit(TCU) 426 of a powertrain control module (PCM) 428 to monitor and recorddiagnostic data from these components. The OBD 412 (as well as the ECU424 and TCU 426) may be in signal communication with various automotivesensors 430 throughout the vehicle 402 that provide sensor data relatingto various systems, components, and devices of the vehicle including,for example, the engine, transmission, chassis, body, and the like. Thesensors 430 may thus indicate the status and condition of these vehiclecomponents. Sensors 430 may also include sensors that can detect thestatus and condition of the vehicle wheels and tires as well as sensorsthat can detect damage to the panels of the vehicle body, e.g.,deformations, dents, punctures, and so forth. Those skilled in the artwill appreciate that the automotive sensors 430 may include, forexample, temperature sensors, pressure sensors, angular positionsensors, linear position sensors, rotational motion sensors, inertialsensors, and the like.

As noted above, the vehicle 402 may transmit data from a vehicle to aninsurance management system 400. The insurance management system 400 mayinclude various systems, subsystems, modules, and the like to facilitateautomated detection of collisions, automated identification ofparticipants, automated determination and attribution of fault, andautomated insurance claims processing. The insurance management system400 may include for example: a communication module 432 that exchangescommunications with the vehicle and other remote systems and devices; acollision detection module 434 that automatically detects vehiclecollisions; a participant identification module 436 that automaticallyidentifies the participants involved in a vehicle collision; a faultdetermination module 438 that automatically determines which participantis at fault for the collision; a repair cost estimation module 440 thatdetermines an estimated repair cost; and an insurance claims processingmodule 442 that automates aspects of the insurance claims process. Thecommunication module may manage the communications exchanged between themodules of the insurance management system 400 and the vehicle 402,mobile computing devices 404, and remote systems. In this regard, thecommunication module 432 may function as the communication gateway forthe insurance management system 400. In some example implementations,the communication module 432 may include one or more web servers formanaging the exchange of communications.

The insurance management system 400 may also include a storage module441 having one or more data stores to facilitate automated collisiondetection, fault determination, and claims processing. The data storesof the storage module 441 may include, for example: a customer datastore 442 that stores biographic or demographic information relating toinsurance customers; a vehicle data store 444 that stores vehicleprofile information; a policy data store 446 that stores the insurancepolicy information for the customers insured by the insurers; a vehicletelematics data store 448 that stores vehicle telematics informationprovided by the vehicles; an event data store 450 that storesinformation relating to collisions; a repair data store 452 that storesvehicle repair information; and a claims data store 454 that storesinformation relating to insurance claims. The data store 440 may alsostore a fault determination ruleset 455 used to determine whichparticipant in a vehicle collision was at fault for the collision.

The customer biographic and demographic data may include, for example,customer name, address, contact information (e.g., mailing address, homephone number, mobile phone number, email address, etc.), date of birth,age, marital status, and so forth. Vehicle profile data may includeinformation that identifies and describes a vehicle, for example, avehicle make, model, year, color, vehicle identification number (VIN),vehicle classification, and so forth. The insurance policy data mayinclude information describing the insurance coverage for an insuredsuch as insurance premium information, deductible information, coveredvehicles, coverage types, and coverage levels. Vehicle telematics datamay include data relating to the movement and operation of a vehicle asdiscussed above with reference to the MVEDR 410. Event data may include,for example, data identifying the date, time, and location (e.g., GPDcoordinates) of the collision. Repair data may include repair estimatescorrelated with or otherwise associated with vehicle telematics data andvehicle diagnostic data. Repair data may also include estimates of totalvehicle value.

A database management system (not shown) may implement an insurancemanagement data model that models the relationships between the customerdata, vehicle data, insurance policy data, vehicle telematics data,event data, repair data, and claims data stored in the data stores442-454 of the storage module 441. The insurance management data modelmay be implemented, for example, as one or more databases that definerespective tables, attributes, and relationships corresponding to theinsurance management data model. The data store may thus store andretain the data described above as respective related or unrelatedrecords in accordance with the insurance management data model.

In addition to the vehicle 402, the insurance management system 400 maybe in signal communication with one or more mobile computing devices 404operated by insurance customers or participants involved in a vehiclecollision. A mobile computing device 404 may store and execute aninsurance application 456, and an individual may interact with theinsurance application to carry out various insurance-related tasks. Inthis way, the insurance management system 400 may communicate withindividuals such as customers and participants. The mobile computingdevice 404 may be a computing device configured to wirelesslycommunicate with the insurance management system 400 via a network. Asnoted above, in some example implementations, the mobile computingdevice may be, for example, a mobile cellular telephone.

The insurance management system 400 may also be in signal communicationwith one or more computing devices of one or more remote systems via anetwork. In this example, the insurance management system 400 is shownto be in signal communication with another insurance management system458, a system 460 of a repair service, a system 462 of a bankinginstitution, a system 464 of a vehicle rental service, a system 466 of avehicle tow service, and other third-party systems 468. The interactionof the insurance management system 400 with these remote systems 458-468will be discussed in further detail below.

Referring to FIG. 5 a flowchart 500 of example method steps forautomatically detecting vehicle collisions, determining fault, andmanaging insurance claims is shown. A collision detection module 434(FIG. 4) of an insurance management system 400 may detect that acollision between vehicles has occurred (step 502). As discussed furtherbelow, the collision detection module 434 may detect the collision basedon a collision notification message received from an ACN 408 or CRM 406of a vehicle or, additionally or alternatively, based on an analysis ofvehicle telematics data received from a vehicle 402.

A participant identification module 436 of the insurance managementsystem 400 may then attempt to identify the participants of thecollision (step 504). As discussed further below, the participantidentification module 436 may attempt to identify the participantsbased, at least in part, on event data 450 obtained by the collisiondetection module 434. The insurance management system 400 may thenautomatically notify the participants that a collision has been detected(step 506). A communication module 432 of the insurance managementsystem 400 may transmit an event notification message to the mobilecomputing devices 404 respectively operated by the participants. Aparticipant may then be able to provide additional information relatingto the collision in order to assist in the fault determination andclaims processing procedures.

Having identified and notified the participants, a fault determinationmodule 438 may attempt to automatically ascertain which participant wasat fault for the collision (step 508). The fault determination module438 may employ a fault determination ruleset 455 to determine andidentify the at-fault participant. The fault determination module 438may analyze vehicle telematics data in accordance with the faultdetermination ruleset 455 to determine and attribute fault. Faultdetermination and attribution will be discussed in further detail below.

A repair cost estimation module 440 may then determine an estimatedrepair cost for the damage caused to a vehicle 402 associated with aparticipant involved in the collision (step 510). The repair costestimation module 440 may determine an estimated repair cost based onvehicle telematics data obtained by the MVEDR 410 of the vehicle 402 anddiagnostic data 452 obtained by the OBD 412 of the vehicle. Thecommunication equipment 418 at the vehicle 402 may transmit the vehicletelematics data and the diagnostic data 452 to the communication module432 of the insurance management system 400. The communication module 432may then forward the vehicle telematics data and diagnostic data to therepair cost estimation module 440 for analysis.

Having estimated the cost to repair the damaged vehicle, a claimsprocessing module 442 of the insurance management system 400 may processan insurance claim associated with one of the participants involved inthe collision (step 512). As noted above, the insurance claim may befiled against the at-fault participant for the participant that was notat fault, or the insurance claim may be filed for the at-faultparticipant. The insurance management system 400 may communicate withthe participant via an insurance application 456 operating at mobilecomputing device 404. The insurance management system 400 may exchangecommunications with the participant via the insurance application 456 toobtain additional information used when processing the insurance claim.In this way, the insurance management system 400 advantageouslyautomates aspects of identifying and responding to collisions.Accordingly, it will be appreciated that some of the steps describedabove and in further detail below relating to identifying and respondingto collisions may performed automatically or, alternatively, performedmanually by an individual.

Automated Accident Detection

As noted above, the collision detection module 434 (FIG. 4) of theinsurance management system 400 may automatically detect collisionsbased on a collision notification message received from an ACN 408 orCRM 406 at a vehicle 402 as well as based on an analysis of vehicletelematics data received from the MVEDR 410 of the vehicle. In FIG. 6A,a flowchart 600 of example method steps for automatically detectingcollisions via an ACN 408 is shown. In this example, an ACN 408 at thevehicle 402 detects a collision (step 602). Accelerometers 420 maymeasure changes to the speed or velocity of the vehicle 402. Forexample, the ACN 408 may determine that a collision has occurred wherethe vehicle 402 undergoes a change in velocity of around 8.0 kilometersper hour (km/h) within an interval of around 150 milliseconds (ms),i.e., a change in velocity of around 4.97 miles per hour (mph) within aninterval of around 0.15 seconds.

Upon determination that a collision has occurred, the ACN 408 maycollect data for inclusion in a collision notification message (step604). The ACN 408 may collect, for example, vehicle telematics data fromthe MVEDR 410, vehicle identification data from the OBD 412, and vehiclelocation data from the GPS receiver 422. The ACN 408 may prepare acollision notification message that includes the vehicle telematicsdata, the vehicle identification data, and the vehicle location data(step 606) and transmit the collision notification message to aninsurance management system 400 (step 608). In some exampleimplementations, the vehicle 402 may store data that identifies theindividual that owns, operates, or is otherwise associated with thevehicle (e.g., a name, a unique identifier, etc.).

A communication module 432 of the insurance management system 400 mayreceive the collision notification message (step 610) and forward thecollision notification message to a collision detection module 434 (step612). In response to receipt of the collision notification message, thecollision detection module 434 may create and store a record of thecollision. As an example, the collision detection module 434 may createa new collision record in the event data store 450 that corresponds tothe collision (step 614). The collision detection module 434 may alsoextract the vehicle telematics data, vehicle identification data, andvehicle location data from the collision notification message and store(or otherwise associate) this data with the event record correspondingto the collision.

The collision detection module 434 may, in some example implementations,request additional collision information or vehicle information from thevehicle 402 involved in the collision (step 616). The collisiondetection module 434 may forward a request for additional information tothe communication module 432 of the insurance management system 400. Thecommunication module 432 may then transmit the request to the vehicle402 where it may be received, for example, at the vehicle communicationequipment 418 or the ACN communication equipment 424. In response toreceipt of the request, the ACN 408, MVEDR 410, OBD 412, CRM 406, oranother vehicle component may obtain the requested information, and thecommunication equipment 418 or 424 may transmit the requestedinformation back to the insurance management system 400.

Having detected the occurrence of a collision, the process to identifythe participants in the collision may be initiated (step 618). As notedabove, the CRM 406 may additionally or alternatively be configured toprepare and transmit the collision notification message as described.Accordingly, the CRM 406 may be additionally or alternatively employedto perform the functions and purpose of the ACN 408 with regard toautomatically detecting collisions.

Referring to FIG. 6B, a flowchart 650 of alternative example methodsteps for automatically detecting collisions is shown. In thisalternative example, the collision detection module 434 of the insurancemanagement system 400 automatically detects collisions. A vehicle 402may continuously transmit vehicle telematics data to the insurancemanagement system 400 where it may be received at the communicationmodule 432 (step 652). The communication module 432 may forward thevehicle telematics data to the collision detection module 434 of theinsurance management system 400 or to the vehicle telematics data store448 of the storage module 441 (step 654). Similar to the approach setforth above, the vehicle telematics data received may include, forexample, vehicle velocity or changes to velocity. The vehicle telematicsdata store 448 may store the vehicle telematics data such that it isrelated to or otherwise associated with vehicle identification data inthe vehicle data store 444 that identifies the vehicle 402 from whichthe insurance management system 400 received the vehicle telematicsdata.

The collision detection module 434 may process and analyze the vehicletelematics data to determine whether a collision has occurred (step656). As an example, the collision detection module 434 may analyze thevehicle telematics data to determine whether a change in velocityoccurred at the vehicle within a relative short time period, e.g., achange in velocity of 8 km/h within 150 ms. The collision detectionmodule 434 may process and analyze the vehicle telematics data as it isreceived from the vehicle 402 or at periodic intervals (e.g., every 30seconds) after having stored the vehicle telematics data in the vehicletelematics data store 448.

If the collision detection module 434 does not detect a collision (step658), then steps 652-656 may be repeated until a collision is detected.If the collision detection module 434 does detect a collision (step658), then the collision detection module may create a record of thecollision (step 660). As noted above, the collision detection module maycreate a new collision record in the event data store 450 thatcorresponds to the collision. The collision detection module 434 mayassociate the vehicle telematics data stored at the vehicle telematicsdata store 448 with the event record stored at the event data store 450.Having associated the vehicle telematics data with the vehicleidentification data in the vehicle data store 444, the event dataassociated with the vehicle telematics data is thus also associated withthe vehicle identification data.

In some example implementations, the collision detection module 434 mayattempt to obtain additional information from a vehicle 402 involved inthe collision. This additional information may include, for example, thevehicle telematics data corresponding to the collision and dataidentifying the vehicle involved in the collision. Accordingly, thecollision detection module 434 may transmit a request to the vehicle 402involved in the collision for additional event or vehicle data (step662), and receive the requested data from the vehicle in a response(step 664). As noted above, an insurance management data model maydefine the relationships between the event and vehicle data received.The event data may include, e.g., the time, date, and location of thecollision as well as vehicle telematics data corresponding to thecollision; and the vehicle data may include, e.g., vehicleidentification data and vehicle diagnostic data. In this way, theinsurance management system 400 may utilize the event and vehicletelematics data when determining the participants involved in thecollision, determining which participant is likely at fault for thecollision, and estimating the vehicle repair cost. Having received theevent data and vehicle telematics data, the insurance management system400 may store the data in the respective data stores 450 and 448 (step666) and initiate determination of the participants involved in thecollision (step 668).

Participant Identification

The participant identification module 436 (FIG. 4) of the insurancemanagement system 400 may automate aspects of the process of identifyingthe participants involved in a vehicle collision. Automated participantidentification advantageously streamlines the process of handling,responding to, and processing information about the collision. Referringto FIG. 7, a flowchart 700 of example method steps for automaticallyidentifying participants involved in a vehicle collision is shown.

Upon determination that a collision has occurred (step 702), aparticipant identification module 436 of the insurance management system400 may attempt to identify the participants involved in the collision.As noted above, the insurance management system 400 may determine that acollision has occurred by receiving a collision notification messagefrom an ACN 408 or CRM 406 installed and operating at a vehicle 402 or,additionally or alternatively, based on vehicle telematics datacollected from the vehicle and analyzed at a collision detection module434. The participant identification process described below assumes thatat least one of the participants is a customer of the insurer thatoperates the insurance management system 400 such that the storagemodule 441 of the insurance management system 400 includes customer andvehicle data corresponding to the participant. In some exampleimplementations, the collision notification message received from thevehicle 402 may directly identify the participant where the notificationmessage includes participant identification information, e.g., a name ofthe individual associated with the vehicle, a customer number, aninsurance policy number, or some other unique identifier. In theseembodiments, the participant identification module 436 may query thecustomer data store 442 or the policy data store 446 using theparticipant identification information included in the collisionnotification message.

In other example implementations, the participant identification module436 may attempt to identify a participant indirectly based on vehicleidentification data included in the collision notification message.Accordingly, the participant identification module 436 may obtain thevehicle identification data associated with the vehicle involved in thecollision (step 704), e.g., vehicle identification data, such as a VIN,included in the collision notification message. The participantidentification module 436 may extract the vehicle identification datafrom the collision notification message and query the vehicle data store444 using the vehicle identification data. Additionally oralternatively, the vehicle identification data may be included with orotherwise associated with the vehicle telematics data provided by thevehicle 402.

The participant identification module 436 may then query the customerdata store 442 for the customer data associated with the vehicleidentification data (step 706). As noted above, the insurance managementdata model may define relationships between the customer data andvehicle data enabling the participant identification module 436 tolookup customer data based on vehicle data. The participantidentification module 436 may then associate the customer with thecollision (step 708), e.g., by associating the customer record for theparticipant with the event record for the collision.

The participant identification module 436 may be configured to identifyeach participant involved in a collision. Accordingly, the participantidentification module 436 may attempt to match an event record for thecollision with a corresponding event record (step 710). The participantidentification module 436 may identify matching event records based onthe event data received from the vehicles involved in the collision,e.g., the time, date, and location of the collision. In particular, theparticipant identification module 436 may determine whether two eventshave matching times, dates, and locations. If the respective time, date,and location of the event records are the same, then the participantidentification module 436 may determine that the event records areassociated with and refer to the same collision.

If the participant identification module 436 identifies a matching eventrecord (step 712), then a participant associated with the matching eventrecord is also likely insured by, e.g., a customer of, the insurer thatoperates the insurance management system 400. Accordingly, theparticipant identification module 436 may determine that thecorresponding participant is a customer (step 714) and query thecustomer data store 442 and vehicle data store 444 for the customer datavehicle data associated with the corresponding participant and vehicleinvolved in the collision (step 716). The participant identificationmodule 436 may thus associate the each of the participants with thecollision, e.g., by associating the customer records for theparticipants with the event records for the collision. In this way, theparticipant identification module 436 associates the incident with eachparticipant involved in the incident (step 718). The participantidentification module 436 may repeat steps 710-718 to associateadditional participants with the collision.

If both participants are insured by the insurer, then the insurer mayautomatically provide respective insurance information to eachparticipant. The participant identification module 436 may retrieve theinsurance information for the first participant and the insuranceinformation for the second participant from the insurance policy datastore 446. The participant identification module 436 may thenautomatically transmit the insurance policy information for the firstparticipant to the second participant and transmit the insurance policyinformation for the second participant to the first participant. Theinsurance policy information may be received at the respective insuranceapplications 456 operating at the mobile computing devices 404 of theparticipants. In this way, the insurance management system 400 automatesthe exchange of insurance information between participants in responseto detection of a vehicle collision.

In some situations, one of the participants involved in the collisionmay not be a customer of the insurer that operates the insurancemanagement system 400. As a result, the participant identificationmodule 436 may not be able to identify a matching event record in theevent data store 450. If the participant identification module 436cannot identify a matching event record in the event data store 450(step 712), then the participant identification module may determinethat the corresponding participant is not a customer of the insurer(step 720) and attempt to identify the corresponding participant usingalternative approaches. For example, other insurance companies maymaintain insurance management systems 458 that also include a collisiondetection module and store event records for collisions. As noted above,the insurance management systems 400 and 458 may be remote relative toone another and in signal communication with each other via a network.The participant identification module 436 may transmit a request to aremote insurance management system 458 to determine whether the remoteinsurance management system includes an event record matching thedetected collision (step 722). The participant identification module 436may include the event data for the collision in the request.

The remote insurance management system 458 may utilize the event datareceived from the participant identification module 436 when attemptingto identify a matching event record, e.g., an event record having amatching time, date, and location. If the remote insurance managementsystem 458 identifies a matching event record (step 724), then theremote insurance management system may retrieve the customer, vehicle,and insurance policy data associated with the corresponding participantand transmit a response to the participant identification module 436that includes this data. The insurance management system 400 may receivethe data associated with the corresponding participant from the remoteinsurance management system 458 (step 726). The participantidentification module 436 may store the data for the correspondingparticipant at the storage module 441 and associate the data for thecorresponding participant with the event record for the collision.

If the remote insurance management system 458 cannot identify a matchingevent record, then the participant identification module 436 may repeatsteps 722-724 to query other remote insurance management systems in anattempt to locate a matching event record for the collision. If amatching event record also cannot be located at other remote insurancemanagement systems, the participant identification module 436 maytransmit a request to one of the identified participants that promptsthe identified participant to obtain the information from thecorresponding participant involved in the collision (step 728). Theparticipant identification module 436 may transmit the request via thecommunication module 432, and the request may be received at theinsurance application 456 operating at the mobile computing device 404of the identified participant. Prompted by the request, the identifiedparticipant may obtain the participant, vehicle, and insuranceinformation from the corresponding participant (step 730). In someexample implementations, the corresponding participant may automaticallytransmit the participant, vehicle, and insurance information using amobile computing device 404. For example, the respective mobilecomputing devices 404 of each user may store participant, vehicle, andinsurance data, and this data may be wirelessly exchanged between themobile computing devices where the exchange is initiated by touching themobile computing devices together.

Upon receipt of the information from the corresponding participant, theinsurance application 456 may transmit the information to the insurancemanagement system 400 where the participant identification module 436may receive the information via the communication module 432 (step 732).The participant identification module 436 may store the participant,vehicle, and insurance information received in the storage module 441and associate the information with the event record for the collision(step 718). In some example implementations, once both participants havebeen identified, the participant identification module 436 may transmita notification to each identified participant (step 734). Thenotification message may indicate that the collision was detected, thatthe participants were identified, and that the insurance managementsystem 400 is automatically processing a response to the collision. Thenotification message may also include the respective insuranceinformation for the participants (e.g., name of insurer, insurancepolicy number, etc.). The communication module 432 of the insurancemanagement system 400 may transmit the notification message to theinsurance applications 456 at the mobile computing devices 400. Aninsurance application 456 may also be configured to enable a participantto indicate that there were no additional participants involved in thecollision, e.g., that the collision involved the participant and astationary object such as a wall or parked vehicle. Once the participantidentification module 436 determines the participants involved in thecollision, the participant identification module may initiate an attemptto determine which one of the participants was at fault for the incident(step 736).

Automated Fault Determination

The insurance management system 400 (FIG. 4) may include a faultdetermination module 438 that automates aspects of determining andattributing fault to one of the participants involved in the collision.Referring to FIG. 8, a flowchart 800 of example method steps forautomatically determining and attributing fault to one of theparticipants is shown. Once the participant identification module 436identifies the participants involved in a collision (step 801), a faultdetermination module 438 may attempt to determine which participantinvolved in the incident is the at-fault participant. The at-faultparticipant may be the participant to which liability for the collisionis assigned. As discussed further below, the fault determination module438 may determine a respective fault probability for each participantinvolved in the collision and identify one of the participants as theat-fault participant based on the fault probabilities. A faultprobability may be a value (e.g., a percentage) that quantifies thelikelihood a participant is the at-fault participant.

The automated fault determination 438 module may receive eventinformation from the respective MVEDRs 410 of the vehicles 402 involvedin the collision (step 802). The fault determination module 438 mayreceive the event data via the communication module 432 of the insurancemanagement system 400. In some example implementations, the faultdetermination module 438 may obtain supplemental driving data related tothe participants involved in the collision (step 804). The supplementaldriving data may include, for example, driver history data and claimhistory data respectively associated with the participants. Drivinghistory data may indicate previous incidents that the drivers have beeninvolved in or citations the driver has received for moving violations.Claim history data may indicate, for instance, previous insurance claimsfiled against the participant. The fault determination module 438 mayobtain the driving history data or the claim history data fromrespective data stores of the storage module 441 or, additionally oralternatively, in response to requests for the supplemental driving datafrom one or more remote third-party systems 468 in signal communicationwith the insurance management system 400.

The fault determination module 438 may analyze the event data and thesupplemental driving data to identify the at-fault participant and todetermine the fault probability values (step 806). The faultdetermination module 438 may apply a fault determination ruleset 456(step 808) when analyzing the event data and supplemental driving data.The fault determination ruleset may be configured, for example, to applythe rules of the road to the vehicle telematics received from thevehicles. In one example, the vehicle telematics data may indicate thatprior to the collision, one of the vehicles made a left turn in front ofan oncoming vehicle. Based on the telematics data, in this example, thefault determination ruleset may indicate that the left-turning vehicleis at fault or at least likely to be at fault. In another example, thevehicle telematics data may indicate that prior to the collision, one ofthe vehicles was moving and the other vehicle was not moving. Based onthe vehicle telematics data, in this other example, the faultdetermination ruleset may indicate that the moving vehicle is at faultor at least likely to be at fault. In an additional example, the vehicletelematics data may indicate that prior to the collision, one of thevehicles was exceeding the speed limit. Based on the vehicle telematicsdata, in this additional example, the fault determination ruleset mayindicate that the speeding vehicle is likely to be at fault. Inresponse, the fault determination module may increase the probabilitythat the speeding vehicle was at fault. In a further example, thevehicle telematics data may indicate that prior to the collision, eachvehicle was moving but one of the vehicles suddenly decelerated causingthe other vehicle to collide with the vehicle. In this further example,the fault determination ruleset may indicate that the deceleratingvehicle is at fault or at least likely to be at fault. Historical datamay also be employed as a factor to determine fault. For example, if thehistorical data indicates that one of the individuals has been more atfault in previous accidents, then the fault determination module mayinitially guess that the individual is at fault for a present accident.Accordingly, the fault determination ruleset may be implemented, forexample, as a decision tree or decision table, using conditionalstatements or switch statements, and combinations thereof. It will beappreciated that various approaches may be selectively employed forimplementing the fault determination ruleset.

Based on the fault determination ruleset 456, the fault determinationmodule 438 may generate one or more fault probability values thatrespectively indicate the likelihood each participant is at fault forthe collision (step 810). The fault determination module 438 may thenattribute fault to one of the participants based on the faultprobability values (step 812). As an example, the fault determinationmodule 438 may attribute fault to the participant associated with thehigher fault probability value.

In some example implementations, the fault determination module 438 maybe configured to determine that fault cannot be accurately attributed toone participant over the other. For example, the fault determinationmodule 438 may conclude that fault cannot be attributed where the faultprobability values for each participant are equal or where thedifference between the fault probability values does not exceed apredetermined threshold. As an example, the fault determination module438 may conclude that fault can be accurately attributed where therespective fault values are 75% likelihood of fault versus 25%likelihood of fault—a fifty percentage point difference—but that faultcannot be accurately attributed where the respective fault values are53% likelihood of fault versus 47% likelihood of fault—only a sixpercentage point difference. Example implementations of the faultdetermination module may be configured to determine that fault can orcannot be determined using additional or alternative thresholds.

If the insurer that operates the insurance management system insures theat-fault party (step 814), then the fault determination module 438 mayassign liability to the insurer, create an insurance claim for theclaimant (step 816), and process the insurance claim (step 818).Processing the insurance claim may include, for example, estimating thecost of repairs for damage to the vehicle associated with the claimantand providing a settlement offer to the claimant. Processing aninsurance claims will be discussed in further detail below.

If the insurer does not insure the at-fault participant (step 814),e.g., where a third-party insurer insures the at-fault participant, thefault determination module 438 may assign liability to the at-faultparticipant (step 820) and contact a third-party insurer that insuresthe at-fault participant to confirm the determination and attribution offault. The fault determination module 438 may transmit the event dataand fault probability values to a remote insurance management system 458of the third-party insurer (step 822). The remote insurance managementsystem 458 may also be configured to automatically determine fault basedon the event data, supplemental driving data, and a fault determinationruleset. In some circumstances, the remote insurance management system458 may be configured to apply the same fault determination ruleset asthe fault determination module 438. In other circumstances, the remoteinsurance management system 458 may apply an alternative faultdetermination ruleset to identify the at-fault participant.

The remote insurance management system 458 of the third-party insurermay likewise analyze the event data and supplemental driving data toidentify the at-fault participant. The third-party insurer may transmita fault determination response back to the fault determination module438 indicating whether the third-party insurer agrees with thedetermination that the at-fault participant is insured by thethird-party insurer. The fault determination module 438 may analyze theresponse from the remote insurance management system 458 to determinewhether the third-party insurer agrees with the determination andattribution of fault (step 824). If the remote insurance managementsystem 458 indicates disagreement with the determination and attributionof fault, e.g., if there is a dispute over fault (step 826), thentypical claim subrogation procedures may be initiated to determinewhether the insurer or the third-party insurer should assume liabilityfor the incident (step 828). If, however, the third-party insurer agreesthat the participant insured by the third-party is at fault, e.g., ifthere is not dispute over fault (step 826), then the fault determinationmodule 438 may automatically assign liability to the third-party insurer(step 830), create an insurance claim for the claimant (step 816), andprocess the insurance claim (step 818). Automatically creating a claimfor the claimant may include automatically filing a claim against theat-fault participant. It will be appreciated that a claim may also beautomatically created and filed for the at-fault participant. As notedabove, processing the claim may include estimating a total repair costand providing a settlement offer. Where liability for the collision isassigned to the third-party insurer, processing the claim may alsoinclude subrogation of the insurance claim.

Damage Estimation

As noted above estimating the cost to repair the damage to a vehicle 402(FIG. 4) involved in the collision may be part of the claims processingprocedure. The insurance management system 400 may include a repair costestimation module 440 that automates aspects of the repair costestimation process. FIG. 9 shows a flowchart 900 of example method stepsfor automatically estimating vehicle repair cost. Having detected that acollision has occurred (step 902), the repair cost estimation module 440may initiate the process of estimating the cost to repair the vehicle402 involved in the collision. The repair cost estimation module 440 maydetermine a total estimated repair cost based at least in part ondiagnostic data and vehicle telematics data provided by the vehicle 402involved in the collision. As discussed above, the OBD 412 of thevehicle 402 may provide the diagnostic data and the MVEDR 410 mayprovide the vehicle telematics data. The repair cost estimation module440 may transmit a request to the vehicle 402 for the diagnostic andvehicle telematics data in response to detecting a collision involvingthe vehicle (step 904). Additionally or alternatively, the vehicle 402may be configured to automatically transmit the diagnostic and vehicletelematics data to the insurance management system 440 in response to acollision detected at the vehicle. The diagnostic and vehicle telematicsdata may be received at the repair cost estimation module 440 via thecommunication module 432 of the insurance management system (step 906).The storage module 441 of the insurance management system 400 may storethe diagnostic data in the repair data store 452 and the vehicletelematics data in the vehicle telematics data store 448. The diagnosticdata and vehicle telematics data may be associated with the event recordfor the collision such that the repair cost estimation module 440 mayquery the respective data stores for the data during the cost estimationprocess.

The repair cost estimation module 440 may analyze the diagnostic andvehicle telematics data (step 908). Analysis of the diagnostic data andvehicle telematics data may include comparing the diagnostic data andvehicle telematics data received from the vehicle 402 to repair datastored in the repair data store 452 of the insurance management system400. The repair data may represent reference information that associatesdiagnostic data and vehicle telematics data with repair cost estimates.The repair cost estimation module 440 may query these repair costestimates from the repair data store 452 based on the diagnostic dataand vehicle telematics data received from the vehicle 402 (step 910). Asnoted above, the diagnostic data may include information that identifieswhich vehicle systems, components, and parts were damaged in thecollision. The repair data store 452 may include repair estimates thatindicate the cost of repairing or replacing the various systems,components, and parts of a vehicle. Accordingly, the repair costestimation module 440 may retrieve the repair estimates for the anydamaged systems, components, or parts identified in the diagnostic dataand determine a total estimated repair cost based, at least in part, onthose repair estimates.

Additionally or alternatively, the repair cost estimation module 440 mayestimate a total repair cost based, at least in part, on the vehicletelematics data received from the vehicle 402. The repair data store 452may include repair estimates that are correlated with vehicle speeds.The repair cost estimation module 440 may determine the speed at whichthe vehicle was traveling when the collision occurred based on thevehicle telematics data received from the vehicle 402. The repair costestimation module 440 may query the repair data store 452 for repairestimates that correlate to the speed of the vehicle 402 when thecollision occurred.

The repair cost estimation module 440 may determine a total repairestimate based on the diagnostic data and the vehicle telematics dataindividually or in combination. The repair cost estimation module 440may also use additional or alternative types of data individually or incombination with the diagnostic and vehicle telematics data to determinea total repair estimate. As noted above, the repair cost estimationmodule 440 may obtain repair estimates from the repair data store 452 ofthe insurance management system 440. Additionally or alternatively, therepair cost estimation module 440 may retrieve repair estimate from aremote third-party system 468 via a network. In these situations, therepair cost estimation module 440 may transmit via the communicationmodule 432 the diagnostic data, vehicle telematics data, or other datato the remote third-party system 468 and receive repair estimates fromthe remote third-party system in response.

Based on the repair estimates received, the repair cost estimationmodule 440 may generate a total estimated repair cost for the vehicle402 involved in the collision (step 912). The repair cost estimationmodule 440 may then transmit via the communication module 432 a repaircost message that includes the total estimated repair cost (step 914).An insurance application 456 operating at the mobile computing device404 of the participant may receive the repair cost message and displaythe total estimated repair cost to the participant. It will beappreciated that the repair cost estimation module 440 may estimate thecost to repair any of the vehicles involved in the collision includingthe vehicle of the at-fault participant as well as the vehicle of theparticipant that was not at fault. It will be appreciated that aspectsof the disclosure may be applicable to other types of insured items. Forexample, sensors may detect when a window breaks such that a claim mayautomatically be generated.

Claims Processing

The insurance management system 400 (FIG. 4) may include a claimsprocessing module 442 that automates other aspects of the claimsprocessing procedure. Referring to FIG. 10, a flowchart 1000 of examplemethods steps for automating aspects of the claims processing procedureis shown. As noted above, the claims processing procedure may includeautomatically creating an insurance claim for a claimant (step 1002) andautomatically determining a total estimated repair cost for the damagedvehicle 402 (step 1004). As discussed further below, the claimsprocessing procedure may include providing a settlement offer to one ofthe participants. As used in the description below, a claimant may be aparticipant for whom an insurance claim has been created as well as aparticipant to whom a settlement offer is provided. The claimant may ormay not be the at-fault participant and may be insured by the insurerthat operates the insurance management system 400 or by a third-partyinsurer.

When processing insurance claims, the claims processing module 442 maydetermine whether the total estimated repair cost exceeds the totalvalue of the vehicle 402 (step 1006). The claims processing module 442may obtain a total estimated value of the vehicle based on vehicleprofile data for the vehicle 402 (e.g., make, model, year, mileage,etc.). The repair data store 452 of the storage module 441 may includemarket value price estimates for vehicles of various makes, models, andyears having various mileage readings. Additionally or alternatively,the claims processing module 442 may obtain the market value priceestimates from a remote third-party system 468 via a network. The claimsprocessing module 442 may provide the vehicle profile data to the remotethird-party system 468 and receive the market value price estimates inresponse.

If the total estimated repair cost exceeds the total estimated value ofthe vehicle 402 (step 1008), then the claims processing module 442 maydetermine that the vehicle is a total loss (step 1010). When the damagedvehicle 402 is determined to be a total loss, the claims processingmodule 442 may automatically initiate transmission of a tow servicerequest to the system 466 of a vehicle tow service (step 1012). The towservice request may include the geographic location of the vehicle 402.In response to receipt of the tow service request, a tow serviceprovider may dispatch a tow truck to the geographic location of thevehicle 402 in order to retrieve the damaged vehicle. The claimsprocessing module 442 may also automatically initiate transmission of avehicle rental request to the system 464 of a remote vehicle rentalservice (step 1014). The rental request may include the geographiclocation of the claimant. In response to receipt of the rental request,a vehicle rental service provider may dispatch a rental vehicle to thegeographic location of the claimant in order to deliver the rentalvehicle to the claimant.

If the total estimated repair cost does not exceed the value of thevehicle 402, then a settlement offer may be provided to the claimant.Before the claims processing module 442 provides a settlement offer tothe claimant, the claims processing module may determine whether theclaimant is insured by the insurer (step 1016). In this way, the claimsprocessing module 442 may determine whether the total estimated repaircost exceeds the deductible for the claimant (step 1018). If theclaimant is insured by the insurer (step 1016) and the total estimatedrepair cost exceeds the deductible for the claimant (step 1020), thenthe claims processing module 442 may not provide a settlement offer tothe claimant. Instead, the claims processing module 442 may transmit arepair cost message to the claimant (step 1022) that indicates the totalestimated repair cost and identifies the insurance deductible of theclaimant. The claims processing module 442 may transmit the repair costmessage to the insurance application 456 at the mobile computing device404 of the claimant.

The claims processing module 442 may also attempt to identify repairservice centers located near the claimant and provide a list of repairservice centers within a predetermined radius (e.g., 5 miles) of theclaimant (step 1024). The insurance application 456 operating at themobile computing device 404 may receive and display the list ofrecommended repair service centers. The claims processing module 442 mayutilize the location data received from the vehicle 402 to identifyrepair service centers located within a predetermined radius (e.g., 5miles) relative to the location of the claimant. The repair data store452 of the storage module 441 may also store information relating torepair service centers and their corresponding geographic locations. Theclaims processing module 442 may query the repair data store 452 for alist of repair service centers in the vicinity of the claimant based onthe geographic location of the claimant. Additionally or alternatively,the list of repair service centers may be stored at a remote third-partysystem 468, and the claims processing module 442 may retrieve the listof repair service centers the vicinity of the claimant from the remotethird-party system 468 via a network. In some example implementations,the claims processing module may identify one or more of the repairservice centers as a preferred repair service center. The insuranceapplication may be configured to receive a selection from the user(e.g., via a button) indicating which repair service center the userintends to patronize. The insurance application may transmit theselection to the insurance management system, and the insurancemanagement system may apply a discount to the insurance policy for thecustomer as a reward for selecting a preferred repair service center.

The claims processing module 442 may also be configured to automate somesteps of the claims resolution process including, for example,automatically determining a settlement offer for the claimant (step1026). The claims processing module 442 may determine a settlement offerfor the claimant where, for example, the vehicle is a total loss (step1008), where the total estimated repair cost exceeds the deductible forthe claimant (step 1020), or where the claimant is not insured by theinsurer (step 1016). The claims processing module 442 may determine thesettlement offer based, at least in part, on the total estimated repaircost. The claims processing module 442 may provide the settlement offerto the claimant (step 1028), e.g., by transmitting a settlement offer tothe insurance application 456 at the mobile computing device 404 of theclaimant. The insurance application 456 may display the settlement offerto the claimant and prompt the claimant to either accept or reject thesettlement offer.

The claimant may provide user input indicating whether the claimantaccepted or rejected the settlement offer, and the insurance application456 may transmit the user input back to the claims processing module442. If the user input indicates that the claimant did not accept thesettlement offer (step 1030), then the claims processing module 442 mayupdate the insurance claim to indicate the claimant rejected thesettlement offer (step 1032) and the typical claims resolution processmay proceed.

If the user input indicates that the claimant accepted the settlementoffer (step 1030), then the claims processing module 442 may initiate atransfer of funds into a bank account associated with the claimant (step1034). The claims processing module 442 may transmit a request to thesystem 462 of a banking institution to transfer funds corresponding tothe settlement offer from a bank account associated with the insurer tothe bank account associated with the claimant. Upon confirmation fromthe banking system 462 that the funds have been transferred, the claimsprocessing module 442 may transmit a deposit notification message to theclaimant indicating that the settlement funds have been deposited intothe bank account associated with the claimant (step 1036). The insuranceapplication 456 at the mobile computing device 404 may receive thedeposit notification message and display the message to the claimant.

Although an insurer provides a settlement offer to a claimant, theinsurer may not be liable for the collision. For example, if the insuredis not the at-fault party, e.g., if the at-fault party is insured by athird-party insurer, the insurer may provide the settlement funds to theinsured and then proceed with subrogation to recover the settlementfunds from the third-party insurer. Accordingly, the claims processingmodule 442 may additionally determine whether the insurer insures theat-fault participant (step 1038) in order to determine whether theinsurer should proceed with subrogation. If the insurer insures theat-fault participant, then there may be no need for subrogation asliability may already be assigned to the insurer. In this regard, wherethe insurer insures the at-fault participant, the claims processingmodule 442 may flag the insurance policy of the at-fault participantsuch that the insurer may subsequently reassess the insurance policy(step 1040), e.g., by applying penalties or adjusting insurance premiumsupon renewal.

Where the insurer does not insure the at-fault participant, the insurermay engage in subrogation with the third-party insurer. The claimsprocessing module 442 may be configured to automate aspects of thesubrogation process. For example, if there is no dispute over faultattribution (step 1042), the claims processing module 442 may transmit arequest to a remote insurance management system 458 operated by thethird-party insurer (step 1044). In response to receipt of the request,the third-party insurer may provide funds to reimburse the insurer forthe settlement funds provided to the claimant. The insurer may receivethe reimbursement funds (step 1046) via, for example, a transfer of thereimbursement funds from a bank account associated with the third-partyinsurer to a bank account associated with the insurer. The claimsprocessing module 442 may receive a deposit notification message fromthe remote insurance management system 458 indicating the transfer offunds. In response to receipt of the deposit notification from theremote insurance management system 458, the insurance management system400 may designate or identify the insurance claim as closed or settled.In this way, the claims processing module 442 of the insurancemanagement system 400 may advantageously subrogate insurance claims witha third-party insurer automatically. If there is a dispute over fault(step 1042), then the claims processing module 442 may initiate typicalsubrogation procedures (step 1048).

The claims processing module 442 may additionally or alternatively beconfigured to allocate settlement payments between the insurer andthird-party insurers. In some example embodiments, the insurancemanagement system may charge a settlement fee when a claim is settledusing the system. The insurance management system may also employ thefault determination probabilities to determine respective portions of asettlement payment shared between one insurer and another insurer. As anexample, if the insurers agree that one of the drivers was 35% at faultand the other driver was 65% at fault, then one of the insurers mayagree to provide 35% of the settlement payment, and the other insurermay agree to provide 65% of the settlement payment. Furthermore, in someexample embodiments, insurers may maintain debit/credit accounts, andthe claims processing module may initiate a credit or debit to therespective accounts for the insurers. Accordingly, in this example,payments between insurers may be a matter of bookkeeping in which theaccounts indicate how much money one insurer owes to or is owed byanother insurer. Actual payments may thus be provided or received atperiodic intervals based on the balances of the debit/credit accounts.

Automated Disturbance Detection for Parked Vehicles

In view of the disclosures above, it will be appreciated that a systemmay be configured to detect other types of physical disturbances suchas, for example, when a moving vehicle impacts a parked vehicle, when avehicle is being towed or stolen, or when a vehicle is otherwisetampered with or disturbed. Bumping or otherwise physically disturbingthe vehicle may trigger the collision and response components installedat the vehicle as well as a message providing notification of thephysical disturbance. As used in this description, a parked vehiclerefers a vehicle that is not moving and is not running (e.g. not turnedon). For comparison, a stopped vehicle or a standing vehicle refers to avehicle that is not moving but is running (e.g., turned on), and amoving vehicle may refer to a vehicle that is currently in motionregardless of whether the vehicle is running or in motion under its ownpower. For example, a vehicle may be moving but not running when thevehicle is being towed or stolen, pushed, affected by gravity (e.g.,where an individual forgets to set the parking brake and the vehicleruns away). As used in this disclosure a running vehicle refers to avehicle that has achieved ignition such that the engine of the vehicleis currently operating. It will be appreciated that the disclosuresprovided in this description may be employed to detect a collision witha vehicle whether that vehicle is parked, standing, stopped, or moving.As an example, the system may be configured to determine that thevehicle is being towed or stolen when the vehicle is determined to bemoving but not running. It will be recognized as indicated above,however, that the vehicle may be moving and not running in othersituations where the vehicle is not being towed (e.g., stolen, pushed).

Referring to FIG. 11, a flowchart 1100 of example method steps fordetecting and responding to a physical disturbance event (e.g., acollision) involving a parked vehicle is shown. The description belowrefers to a collision event by way of example, but aspects of thedisclosure may be applicable to other types of physical disturbanceevents. The detection and response components of a parked vehicle may beconfigured to detect and respond to a collision at the vehicle (step1102) even when the vehicle is parked. As an example, a CRM 406 (FIG. 4)of the vehicle 402 may be configured to enter a low power mode (e.g., asleep mode, a standby mode, a hibernation mode) when the vehicle isparked. In response to receipt of a notification that a collision hasoccurred at the vehicle 402, the CRM 406 may enter an active mode (e.g.,resume, wake up) in order to respond to the vehicle collision.

The accelerometers 420 of the ACN 408 or other sensors 430 at the parkedvehicle 402 may detect a collision as described above. In response tothe collision, the ACN 408 or other sensors 430 may provide anotification to the CRM 406 that a collision has occurred. In responseto receipt of the notification, the CRM 406 may carry out various stepsin order to respond to the collision. It will be appreciated that theACN 408 or other sensors may provide notification of a collision thathas occurred at the vehicle 402 when the vehicle is both running and notrunning as well as when the vehicle is both moving and not moving.

As shown by way of example in FIG. 11, the CRM 406 may determine if thevehicle 402 was running when the disturbance event occurred (step 1104),e.g., by querying the OBD 412 or MVEDR 410. If the vehicle 402 wasrunning when the disturbance event occurred (step 1106), then the CRM406 may determine that the vehicle 402 was not parked when thedisturbance event occurred (step 1108), e.g., that the vehicle wasmoving, stopped, or standing when the disturbance event occurred. If theCRM 406 determines that the vehicle 402 was not running when thedisturbance event occurred (step 1106), then the CRM may determinewhether the vehicle was moving when the disturbance event occurred (step1110). The CRM 406 may determine whether the vehicle 402 was movingalso, e.g., by querying the OBD 412 or MVEDR 410. If the CRM 406determines that the vehicle 402 was moving but not running when thedisturbance event occurred (step 1112), then the CRM may determine thatthe vehicle is being towed or stolen (step 1114). If the CRM 406determines that the vehicle 402 was not moving (step 1112) and notrunning (step 1106) when the disturbance event occurred, then the CRMmay thus determine that the vehicle was parked when the disturbanceevent occurred (step 1116).

In response to detection of the disturbance event, the CRM 406 mayinitiate various steps in order to respond to the disturbance event. TheCRM 406 may, for example, activate one or more recording devices 414 or416 at the vehicle 402 (step 1118), e.g., the A/V equipment, to recordthe area surrounding the vehicle for a period of time following thedisturbance event (step 1120). The recording devices 414 or 416 mayrecord the area surrounding the vehicle 402 following detection of thedisturbance event for a predetermined period of time, e.g., for 30seconds after detection of the disturbance event. In this way, therecording devices 414 or 416 may capture and retain informationregarding the circumstances of the disturbance event including possiblyinformation identifying a vehicle that collided with the parked vehicle402 (e.g., a license plate, vehicle make, model, color, etc.),information identifying an individual tampering with the vehicle, orinformation indicating that the vehicle is being towed or stolen. Itwill be appreciated that the recording devices 414 or 416 may also beemployed to record audio or video for collisions detected when thevehicle is moving.

The CRM 406 may also generate and transmit a collision notificationmessage to an insurance management system 400 (step 1122). The collisionnotification message may include information relating to the vehicle 402and the collision including, for example, vehicle identification data(e.g., VIN, make, model, year, etc.), location data (e.g., GPScoordinates), event data (e.g., audio or video recordings), anddiagnostic data. The communication equipment 418 at the vehicle 402 maytransmit the collision notification message to the insurance managementsystem 40 via a network (e.g., cellular, IP-based, etc.) Thecommunication module 432 of the insurance management system 400 mayreceive the collision notification message and forward the message toother modules at the insurance management system for further processing.

As an example, the insurance management system 400 may leverage the GPSdata received from the vehicle to identify high-risk areas based on whattype of area it is. For example, the insurance management system mayidentify highly dense urban areas as relatively riskier compared to lessdense rural areas. As another example, the insurance management systemmay identify large parking lots in commercial areas as relativelyriskier compared to driveways in residential areas. The insurancemanagement system 400 may also leverage the velocity of impacts toidentify relatively high-risk areas. For example, areas in which lowvelocity impacts occur may be less risky than areas in which highvelocity impacts occur. It will be recognized that the insurancemanagement system may leverage additional or alternative types ofinformation from the vehicles to identify additional or alternativeaspects of the areas in which the vehicles travel and reside.

The participant identification module 436 of the insurance managementsystem 400 may identify the owner of the parked vehicle 402 based, e.g.,on the vehicle information (e.g., the VIN) as discussed above. Theparticipant identification module 436 may retrieve the contactinformation for an individual associated with the parked vehicle 402(e.g., an email address, a cellular phone number, etc.) and provide acollision notification message to that individual (step 1124). In someexample implementations, the CRM 406 may be configured to transmit thecollision notification message directly to the individual associatedwith the parked vehicle 402. The CRM 406 may store and retain thecontact information for the individual and utilize this contactinformation to contact the individual directly in response to detectinga collision at the vehicle 402. The insurance application 456 at themobile computing device 404 of the individual may receive and displaythe collision notification message. In response to receipt of thecollision notification message, the individual may return to the vehicle402 in order to assess any damage, engage with the at-fault participantto exchange insurance information, and initiate insurance claims.

In some example implementations, receipt of the collision notificationmessage at the insurance management system 400 may trigger automaticidentification of the participants involved in the collision (step1126), automatic selection of one of the participants as the at-faultparticipant (step 1128), and automatic claims processing for insuranceclaims associated with the collision (step 1130), e.g., an insuranceclaim against the at-fault participant. The participant identificationmodule 436 of the insurance management system 400 may be configured toidentify the at-fault participant that collided with the parked vehicle402. If the vehicle associated with the at-fault participant is alsoconfigured to communicate with an insurance management system (e.g.,insurance management system 400 or 458) as described above, then theparticipant identification module 436 may identify the at-faultparticipant based on a collision notification message or vehicletelematics data received from the vehicle associated with the at-faultparticipant.

The participant identification module 436 may also be configured toidentify the at-fault participant based on the recording obtained by theparked vehicle 402. As an example, the parked vehicle 402 may providethe recording obtained after the collision occurred to the insurancemanagement system 400, and the insurance management system may processthe recording to extract information identifying the vehicle thatcollided with the parked vehicle. The participant identification module436 may, for example, employ various image-processing techniques toextract the license plate number of the vehicle and query a third-partysystem 468 for information identifying the individual associated withthe vehicle. Having identified the participant associated with themoving vehicle, the fault determination module 438 of the insurancemanagement system 400 may select the individual associated with thecolliding vehicle as the at-fault participant. The claims processingmodule 442 may thus automatically file an insurance claim against theat-fault participant.

In some example implementations, the disclosures described above may beemployed to distinguish between prior damage to the parked vehicle andcurrent damage to the parked vehicle caused by the collision. Forexample, the insurance management system 400 may be employed to identifyprior damage to a vehicle that did not occur as a result of a recentcollision. As an example, the vehicle sensors may indicate that damageto the right front bumper occurred prior to the collision (e.g., usingtimestamp information associated with sensor readings). If the recentcollision resulted in damage to the left front bumper, then theinsurance management system may thus determine that only the damage tothe left front bumper was due to the collision with the damage to theright front bumper being prior damage. The insurance management systemmay also employ the sensor readings to determine the likelihood ofdamage caused by a collision. For example, if the vehicle sensors detecta low velocity impact at the rear of the vehicle such that the vehiclemoved forward without backward recoil, then the insurance managementsystem may determine that no impact occurred at the front of thevehicle. As a result, the insurance management system may determine thatany damage at the front of the vehicle is not due to the recentcollision. It will be recognized that the insurance management modulemay be configured to identify current damage from previous damage inadditional or alternative situations.

In further example implementations, the disclosures described above maybe employed to detect fraud. Because the insurance management system 400may be configured to distinguish current damage from previous damage asdescribed above, the insurance management system may also be able todetect attempts at fraud. For example, if an individual claims previousdamage as current damage, the insurance management system may flag theclaim as fraudulent. As another example, if the velocity informationprovided by the vehicle do not correlate with the amount of damageclaimed by the individual, then the insurance management system may alsoflag the claim as fraudulent. It will be recognized that the informationreceived from the vehicle may be employed by the insurance managementsystem to identify additional or alternative types of fraudulentactivities.

The foregoing descriptions of the disclosure have been presented forpurposes of illustration and description. They are not exhaustive and donot limit the disclosure to the precise form disclosed. Modificationsand variations are possible in light of the above teachings or may beacquired from practicing of the disclosure. For example, aspects of thedescribed implementation include software but aspects of the presentdisclosure may be implemented as a combination of hardware and softwareor in hardware alone. Additionally, although aspects of the presentdisclosure are described as being stored in memory, one skilled in theart will appreciate that these aspects can also be stored on other typesof non-transitory computer-readable media, such as secondary storagedevices, like hard disks, floppy disks, or CD-ROM or other forms of RAMor ROM.

What is claimed is:
 1. A computer-implemented method for automaticallyresponding to a vehicle collision comprising: receiving, through acommunication module, one or more communications from a vehicle;determining, automatically at a collision detection module, that acollision involving the vehicle has occurred based, at least in part, onone or more of the communications; identifying, automatically at aparticipant identification module, one or more participants involved inthe collision based, at least in part, on one or more of thecommunications; and selecting, automatically at a fault determinationmodule, one of the participants as an at-fault participant based, atleast in part, on a comparison of a fault determination ruleset tovehicle telematics data included in one or more of the communications.2. The computer-implemented method of claim 1 further comprising:calculating, automatically at a repair cost estimation module, anestimated repair cost based, at least in part, on vehicle diagnosticdata included in one or more of the communications received from thevehicle; determining, automatically at a claims processing modulewhether to file an insurance claim associated with one of theparticipants that includes the estimated repair cost; and filing,automatically using the claims processing module, the insurance claim inresponse to a determination to file the insurance claim.
 3. Thecomputer-implemented method of claim 1 wherein determining that thecollision involving the vehicle has occurred includes: analyzing, usingthe collision detection module, the vehicle telematics data;determining, automatically at the collision detection module, whetherthe vehicle experienced a predetermined change in velocity within apredetermined time period; and determining, automatically at thecollision detection module, that the collision has occurred in responseto a determination that the vehicle has experienced the predeterminedchange in velocity within the predetermined time period.
 4. Thecomputer-implemented method of claim 1 wherein a record of the collisionis automatically created in response to a determination that thecollision has occurred and identifying the one or more participantsinvolved in the collision includes: initiating an attempt to find amatching record based, at least in part, on the vehicle telematics data;and in response to finding the matching record, identifying aparticipant associated with the matching record as one of theparticipants involved in the collision.
 5. The computer-implementedmethod of claim 4 wherein identifying one or more participants involvedin the collision further includes: determining that the matching recordwas not found at a local insurance management system; initiating arequest to a remote insurance management system wherein receipt of therequest at the remote insurance management system triggers an attempt tofind the matching record at the remote insurance management system; andin response to receipt of a notification that the matching record wasfound at the remote insurance management system, identifying theparticipant associated with the matching record as one of theparticipants involved in the collision.
 6. The computer-implementedmethod of claim 1 wherein selecting one of the at-fault participant isfurther based on a comparison of the fault determination ruleset tosupplemental driving data associated with at least one of theparticipants.
 7. The computer-implemented method of claim 6 wherein theparticipants involved in the collision include a first participant and asecond participant and further comprising: determining, automatically atthe participant identification module, first insurance informationassociated with the first participant and second insurance informationassociated with the second participant; initiating, automatically at theparticipant identification module, a first insurance notification to thefirst participant and a second insurance notification to the secondparticipant; and wherein the first insurance notification includes thesecond insurance information and the second insurance notificationincludes the first insurance information.
 8. The computer-implementedmethod of claim 7 wherein determining the second insurance informationassociated with the second participant includes: determining that thesecond participant is insured by an insurance provider associated with aremote insurance management system; initiating an insurance informationrequest to the remote insurance management system; and wherein receiptof the insurance information request at the remote insurance managementsystem triggers an insurance information response to the participantidentification module that includes the second insurance informationassociated with the second participant.
 9. A system for automaticallyresponding to a vehicle collision comprising: a communication moduleconfigured to communicate with a vehicle; a data store configured tostore vehicle telematics data, vehicle diagnostic data, and a faultdetermination ruleset; and a processor configured to i) determine that acollision involving the vehicle has occurred based, at least in part, onone or more communications received from the vehicle, ii) identify oneor more participants involved in the collision based, at least in part,on one or more of the communications, iii) select one of theparticipants as an at-fault participant based, at least in part, on acomparison of a fault determination ruleset to the vehicle telematicsdata, iv) calculate an estimated repair cost based, at least in part, onthe vehicle diagnostic data, and v) determine whether to file aninsurance claim associated with one of the participants that includesthe estimated repair cost.
 10. The system of claim 9 wherein theprocessor is further configured to: file the insurance claim in responseto a determination to file the insurance claim; determine a settlementoffer for the insurance claim based, at least in part, on the estimatedrepair cost; initiate transmission of the settlement offer to theparticipant; and determine whether the participant accepts thesettlement offer.
 11. The system of claim 10 wherein the processor isfurther configured to: initiate a deposit corresponding to thesettlement offer into a bank account associated with the participant inresponse to a determination that the participant accepted the settlementoffer; and upon receipt of confirmation of the deposit, initiate anotification to the participant that indicates funds corresponding tothe settlement offer were successfully deposited.
 12. The system ofclaim 11 wherein the funds are deposited into the bank accountassociated with the participant from a first bank account associatedwith a first insurance provider, and wherein the processor is furtherconfigured to: determine whether the participant is the at-faultparticipant; in response to a determination that the participant is notthe at-fault participant, initiate a reimbursement request to a remoteinsurance management system; and wherein receipt of the reimbursementrequest at the remote insurance management system triggers a depositcorresponding to the settlement offer from a second bank accountassociated with a second insurance provider into the first bank accountassociated with the first insurance provider.
 13. The system of claim 9wherein the processor is further configured to: determine whether theestimated repair cost exceeds an insurance deductible for one of theparticipants; determine to file the insurance claim in response to adetermination that the estimated repair cost exceeds the insurancedeductible; and in response to a determination that the estimated repaircost does not exceed the insurance deductible, determine not to file theinsurance claim, identify one or more repair service centers within apredetermined radius around a geographic location of the participant,and initiate a notification to the participant that lists the one ormore repair service centers.
 14. The system of claim 9 wherein theprocessor is further configured to: determine whether the vehicle is atotal loss based, at least in part, on the estimated repair cost and anestimated value of the vehicle; initiate a tow service request to asystem of a vehicle tow service in response to a determination that thevehicle is a total loss, wherein the tow service request indicates ageographic location of the vehicle; and further in response to adetermination that the vehicle is a total loss, initiate automatically avehicle rental request to a system of a vehicle rental service, whereinthe vehicle rental request indicates a geographic location of theparticipant involved in the collision that is associated with thevehicle.
 15. A non-transitory computer-readable storage medium havingcomputer-readable instructions stored thereon that, when executed by aprocessor, cause the processor to perform steps for automaticallyresponding to a vehicle collision, the steps comprising: receiving oneor more communications from a vehicle; determining that a collisioninvolving the vehicle has occurred based, at least in part, on one ormore of the communications; identifying one or more participantsinvolved in the collision based, at least in part, on one or more of thecommunications; selecting one of the participants as an at-faultparticipant based, at least in part, on a comparison a faultdetermination ruleset to vehicle telematics included in one or more ofthe communications; calculating an estimated repair cost based, at leastin part, on vehicle diagnostic data included in one or more of thecommunications; and filing an insurance claim associated with one of theparticipants that includes the estimated repair cost.
 16. Thecomputer-readable storage medium of claim 15 wherein selecting one ofthe participants as the at-fault participant includes: generatingrespective fault probability values for each of the participantsinvolved in the collision based, at least in part, on the vehicletelematics data; and identifying one of the participants as the at-faultparticipant based on the fault probability values.
 17. Thecomputer-readable storage medium of claim 16 wherein identifying one ofthe participants as the at-fault participant includes: determining whichfault probability value is largest; and identifying the participantassociated with the largest fault probability value as the at-faultparticipant.
 18. The computer-readable storage medium of claim 16wherein identifying one of the participants as the at-fault participantincludes: determining whether one of the fault probability valuesexceeds a predetermined probability threshold; and in response to adetermination that the fault probability value exceeds the predeterminedthreshold, identifying the participant associated with the faultprobability value as the at fault participant.
 19. The computer-readablestorage medium of claim 15 wherein the computer-readable instructions,when executed by a processor, cause the processor to perform stepsfurther comprising: initiating a fault confirmation request to a remoteinsurance management system wherein receipt of the fault confirmationrequest at the remote insurance management system triggers verificationof the participant as the at-fault participant; determining whether theparticipant was verified at the remote insurance management system asthe at-fault participant based, at least in part, on a faultconfirmation response received from the remote insurance managementsystem; and assigning liability for the collision to an insuranceprovider that insures the at-fault participant in response to adetermination that the remote insurance management system verified theparticipant as the at-fault participant.
 20. The computer-readablestorage medium of claim 15 wherein the computer-readable instructions,when executed by a processor, cause the processor to perform stepsfurther comprising: initiating a reimbursement request to the remoteinsurance management system for reimbursement of settlement funds paidout for the insurance claim; and wherein receipt of the reimbursementrequest at the remote insurance management system triggers automaticreimbursement from an insurance provider that insures the at-faultparticipant.